6. Information Initiatives & Policy Directions

SDOT Information Infrastructure Initiatives Framework

Information as a critical service

To serve the information needs and protect the interests and safety of the traveling public, SDOT has to approach information about the transportation network as a critical service, during normal operating conditions and in the face of system shocks (e.g., an earthquake or climate crisis impacts) and stressors (e.g., a spike in the number of travelers).  The department has to push out reliable information in ways that the public and the providers that serve the public can use readily. This is particularly true of critical information that changes rapidly and must be delivered in real-time or near real-time.

To fulfill this new role and critical service, SDOT needs to manage information and build information infrastructure that delivers accurate information where and when it is needed; in ways that work for the users and the providers.

Internal SDOT Initiatives

Based on the mission, vision, values and goals, information imperatives, and the traveler and actor information needs; and, to manage Seattle’s transportation network in the age of transportation information, SDOT will pursue the following initiatives:

Developing a Real-time Right of Way Conditions Map that will built on an SDOT Transportation API Strategy. The API strategy will be managed by an Information Delivery Unit. This new unit will work with the Asset Management team and the asset data owners and to formulate, implement and enforce a department-wide Data Governance Policy. The policy will include the development of and conformity to SDOT data standards which will help us to expand and maintain SDOT’s Data Library. The backend of operations also requires an SDOT Supply Inventory system, which will be a key building block and requirement for a Mobile Digital Workforce Initiative. The Digital Workforce will also be supported by a Future Right of Way Conditions Map.

Four additional projects are critical to building out SDOT’s transportation information infrastructure: the Urban Goods Delivery Initiative; Open311 or similar; Right of Way Sensing and Beacon Infrastructure; and, Machine Learning and Predictive ROW AI.

We explain each of the initiatives and projects below[41]:

1.   The Real-Time Right of Way Conditions Map

SDOT’s current right of way map is built on GIS and database technology that handles static data well but struggles when data needs to be constantly updated, especially in real-time.

SDOT needs to build a right of way map that handles dynamic (constantly changing) information, published in real-time to a web-based (web-native) map platform such as Open Street Map or SharedStreets (which is built on Open Street Map). The goal is to have data feeds and APIs that other providers can use through machine-to-machine (or system-to system) information flows.

This would be separate from the existing right of way map that locates all of SDOT’s (and the city’s) fixed assets on the right of way.[42] The Real-time Right of Way Conditions Map should include:

  • Real-time traffic conditions
  • Real-time bus and rail routes
  • Real-time locations of high-capacity transit
  • Real-time shared-vehicle availability
  • Real-time sidewalk, road and bridge closures
  • Real-time locations of urban deliveries
  • Real-time parking availability

The Real-time Right of Way Conditions Map will be built on the SDOT Transportation API Strategy.

2.  The SDOT Transportation I/O (SDOT’s transportation API strategy)

To deliver on the information needs of the Real-time Right of Way Conditions Map listed above and to provide information that can be ingested in real-time by transportation information and service providers, SDOT needs to build a coherent, enterprise-level strategy of pushing data out and taking data in via APIs and data feeds.

The Real-time Right of Way Conditions Map and the transportation API strategy need to provide information that is accessible and easily portable or interpreted into channels that do not require the traveling public to use personal devices or payment or subscription to internet access.

SDOT’s transportation API strategy needs to be managed by the SDOT Information Delivery Unit.


The Information Delivery Unit (IDU) will be tasked with implementing the SDOT Transportation API Strategy and the build out of the Real-time Right of Way Conditions Map. The IDU will set out information delivery standards (up time, data specs, etc.) for all data and information the department shares via API data feeds. The unit will manage or oversee the projects to deliver each API. It will be accountable for usability, dependability and performance of the APIs. It will be accountable for the information imperatives set forth in this plan and ensure that the systems that deliver the APIs and data feeds are resilient.

The IDU will coordinate Seattle Information Technology Department (Seattle IT) and with the asset owners and the divisions responsible for the real-time data that will feed the APIs.

The IDU will work with SDOT units, and particularly with:

  • Transportation Operations for approved traffic control plans, and signs and signals
  • Maintenance Operations for maintenance road closures, incidents and customer complaints
  • Capital Projects and Roadway Structures for capital project schedules and bridge status and conditions
  • Street Use for permitted road closure schedules
  • Transit and Mobility for fixed routes and new mobility service providers
  • Policy and Planning and Project Planning and Development for plans and the informational requirements of planned infrastructure
  • Asset Management for asset locations, conditions and inventories
  • Communications for automated notices

The IDU could be housed under Transportation Operations and, in coordination with the Data Librarian, will maintain SDOT’s data inventory.

Working with Transit and Mobility, the IDU will also set standards and performance agreements for incoming API and data feeds from information and mobility service providers.

Special Attention to Information Accessibility

The city’s transportation information infrastructure must provide for the needs of all travelers, including those who may have special challenges or may not have adequate access to information. SDOT should develop a standard tools, akin to the Racial Equity Toolkit (RET) to evaluate the accessibility of transportation information across modes and demographics.

The tools should be used to look at current conditions and identify opportunities for improvements, as well as to evaluate proposed projects that may impact the information ecosystem. The tools should include:

  • an assessment of how connectivity issues affect information delivery to travelers;
  • an assessment looking at user-specific issues (e.g., vision or hearing impairment), both under current conditions and any previous conditions where connectivity issues have been addressed; and,
  • a guide to creating an action plan to address both connectivity and user-specific access issues identified in the preceding sections.

The IDU will work with the Asset Management team and the asset data owners and to formulate, implement and enforce SDOT’s new Data Governance Policy and to maintain SDOT’s Data Library.


4.   Data governance policy

SDOT, in consultation with the Seattle IT, will set rules for the handling of SDOT’s transportation data. The policy will be shaped by the city’s privacy principles, surveillance ordinance, and mobility data management policies.

The policy will set the frame and goals for addressing equity issues concerning data collection, use and distribution.

The policy will set accountability for managing SDOT datasets, including protocols for upkeep, validation, testing, and archiving. It will set data integrity and data delivery as key performance indicators for asset and program owners. It will set reporting requirements for dataset owners.

In coordination with Seattle IT and SDOT’s privacy champion, the policy will reinforce the rules on handling personally identifiable information in all SDOT datasets, APIs, and data feeds.

The policy will require all completed SDOT capital projects (whether delivered by contractors or by crews) to deliver digital records of the as-built assets upon turnover.  It will ensure the reporting of completed asset information to help track SDOT’s commitments.

The digital records will conform to SDOT’s data standards so that the records can readily be uploaded to SDOT’s asset inventory and Data Library.

5.  SDOT Data Library

The SDOT Data Library will be the standardized central catalog of all the data that SDOT collects. The Data Library will make it easier to find, understand, and use SDOT data. The Data Library serves two primary purposes:

  • Centralized, managed access to all data and metadata.
  • Continuous data monitoring

In conjunction with the Data Governance Policy, the Data Library will ensure that SDOT standardizes the way it collects and maintains information and assures that SDOT staff have access to, and can provide the public with, the most up-to-date information and analysis.

6. Updated and validated asset inventory

SDOT’S digital records of its physical assets must reflect accurately the assets on the ground. SDOT will invest resources in updating and maintaining its asset inventory so that there are minimal discrepancies between what is in our records and what is built.

An up-to-date and validated physical asset inventory reduces risks and mitigates possible liabilities for SDOT when issues of information availability and validity arise.

The updated and validated asset inventory will deploy protocols to ensure accurate data is uploaded to the inventory upon delivery of private construction and crew built capital projects. All assets deployed in the transportation network must be geolocated, and this information carried in the asset inventory.

Particularly for crew-delivered projects, the asset inventory must rely on the SDOT supply inventory.

7. SDOT Supply Inventory

SDOT needs to deploy and maintain a supply inventory, particularly for physical objects in its transportation infrastructure (e.g., signs, signals, and signal components). The supply inventory will help SDOT to track the locations of fixed and interchangeable assets it deploys and maintains.

The supply inventory will automate geolocating assets and will facilitate inspection, maintenance, and repair work.

The supply inventory is a key building block for SDOT’s Mobile Digital Workforce Initiative.

8.  Mobile digital workforce initiative 

SDOT will invest in tools that allow SDOT crews and project personnel to access and deliver information while in the field. This includes the status of repair work and capital work, the conditions of existing assets, and findings from inspections. It includes digital notifications of emergency road closures, asset attribute changes, and real-time information on incidents

The mobile digital workforce initiative will equip SDOT staff (particularly crews, project and construction managers, and inspectors) with the application environment (software) and hardware (phones and tablets) they need to gather, transmit, receive, and update information in situ. This assures that SDOT has the latest information about conditions in the right of way. This includes purchasing or developing a suite of software tools that are mobile from the ground up (built for phones or tablets) that interface with SDOT’s existing right of way map (for assets) and the proposed real-time right of way conditions map.

The Mobile Digital Workforce initiative will be supported by a Future Right of Way Conditions Map.

9.   Future Right of Way Conditions Map

SDOT needs a map to display the future (planned or permitted) conditions of the right of way. Currently, this information is distributed in various databases or GIS datasets and files, or in documents. As with the Real-time Right of Way Map, the goal is to have data feeds and APIs that other providers can use through machine-to-machine (or system-to system) information flows.

  1. Traffic Control Plans (TCP) on Map
    SDOT receives and processes about 60 TCPs each week. These plans are often submitted as paper or PDF (or scanned PDF) files. Each plan must be reviewed against existing traffic configurations and TCPs for previously approved plans. The process is tedious and intensive. Street Use’s dotMaps has facilitated showing where and when permitted closures are located and scheduled but accessing the TCPs is still a manual process of looking through various digital files.The TCP on Map project will shift TCP submissions so they begin with locating the project on a web-based but access-restricted map and schedule. The applications and plans should then be accessible via the web map, with the elements of the control plans (lane and sidewalk closures, sign placements, etc.) viewable from the map itself.

    The TCP on Map project, combined with or layered onto dotMaps, or as an expansion of dotMaps or a similar service, will provide SDOT staff with easily accessible situational information on current and future permitted road closures.

  2. Plans on Map
    SDOT publishes its plans (modal plans, district plans and implementation plans) as downloadable online publications or as topical websites. To illustrate the plans, the publications and/or the websites include map graphics. The map graphics are flat images that may be partially interactive. The maps are usually created on a GIS-generated base map and may be stored as GIS files.The Plans on Map project will deliver these plans on a web-based map. The map-based interface will allow the public and stakeholders to view any plan situated in the geography and in spatial relation to other plans.SDOT will need to determine at what stage of the planning process the plans should appear on the map or develop a convention to indicate what stage a plan is in.
  3. Capital Projects on Map
    Future SDOT construction projects, whether contractor or crew-delivered, should be available on a map with as much detail as is possible, including data on construction and road closure schedules.

The TCP on Map, Plans on Map, and Capital Projects on Map projects would constitute the core of a web-based Future Right of Way Conditions Map that, along with Streets Illustrated, will allow customers and stakeholders to understand how SDOT is shaping and managing the future of the city’s right of way and transportation network.

Four additional projects are critical to building out SDOT’s transportation information infrastructure:

10.  Urban goods delivery data initiative

Urban goods delivery is, by some accounts, the fastest growing segment of the transportation system.[43] This includes e-commerce deliveries to homes and businesses, and grocery and restaurant deliveries. Data-wise, this segment is highly integrated across the supply chain. The online ordering systems connect directly to order fulfilment and delivery systems. The customer can know the predicted day and time of the delivery and can confirm delivery even remotely.

This information is critical to managing the transportation system. Current, historic and predictive data can help SDOT manage traffic more effectively along arteries and in urban centers and villages.

11.   Open311

Open311[44] or a similar open data protocol for requests will allow SDOT to exchange information with other government units using the Open311 standard. It will improve the flow of information around customer complaints and road closures by making the information exchange all digital.

Open311 or a similar protocol will feed into SDOT’s APIs and be incorporated into the Real-time Right of Way Conditions Map to track SDOT’s response.

12.  Right of way sensing and beacon infrastructure

To determine traffic flow, speeds and congestion, SDOT has already deployed various sensing devices[45], including WiFi sensors and license-plate readers, in specific areas of the transportation network. The data these sensors has produced has been critical to assessing and analyzing the flow of traffic downtown.

SDOT needs to expand and continue investing in (and maintaining) its sensor network, and invest in additional real-time sensors that provide information on:

  • Pedestrian and public-life counters
  • Bike and micro-mobility counters
  • Public transit stations (wait times and volumes of passengers)[46]
  • Arterials

SDOT should consider investing in wireless beacons to broadcast the location of infrastructure such as

  • Arterials
  • Bus stops
  • Load zones

As with the WiFi sensors and the license-plate readers, SDOT will follow a strict protocol to protect privacy so that the data from these sensors are not used for unauthorized surveillance. [47]

The data from these sensors, combined with the data from APIs (displayed on the Real-time Right of Way Conditions Map) will allow SDOT to employ machine learning and predictive right of way AI.

13.  Machine learning and predictive right of way AI

Ideally, SDOT should leverage the transportation information it will generate and receive by deploying machine learning to get a deeper sense of the traffic and transportation patterns of the city. The information and data could help develop a predictive algorithm (AI) for right of way conditions.

The predictive algorithms should be explainable and transparent. The development should be guided by SDOT values and by the information imperatives set forth in this plan. The algorithms should help SDOT set forth further policies to a) accelerate decarbonization; 2) advance equity; 3) protect privacy; and, sustain markets.

Further Considerations

As SDOT pursues technologies to deploy the items on this backlog it must focus on:

  • Building robust, flexible, and reliable infrastructure. Data and information systems are critical business assets, essential to managing the right of way successfully. SDOT should avoid technology that could lock the department into proprietary systems. The technology components should be robust, able to function in times of crisis and high demand, and reliable. Data acquisition systems must be evaluated, refined, and improved continually. (This assumes the provision of adequate resource, including staff.) Data validation protocols should be built into the systems and processes.
  • User-centricity. Too often systems and solutions are developed based on incomplete business needs or business needs develop without the context of the larger picture. SDOT should deploy a customer-first approach, putting the needs of users first and having those needs drive requirements. To do this, the department needs to develop a culture of user testing. This means ensuring that whenever a new information process or technology is proposed, a sample of intended users is surveyed and, if possible, observed using the new process or technology. These user tests may reveal that a different or modified solution will better meet the needs of users. Similarly, a diverse and representative group of internal and external stakeholders must inform policy development.
  • Traveler information privacy and data security. All data and information generated, captured, shared, used, or stored must be held to the highest standards of privacy and security. These standards must ensure equitable protections for all. Transparency, accountability, and equity are key principles to uphold.
  • Equitable access to transportation information. Informed by known historical inequities, especially as related to technology and information, SDOT should put in place safeguards to mitigate known inequities, and should continue to look for and mitigate newly recognized inequities.
  • Strong partnerships. As transportation continues to evolve at a fast clip, projects must be developed with an eye to establishing and sustaining strong partnerships in the ecosystem.

Figure 7: The SDOT Information Infrastructure Initiatives Stack

The user requirements of the above-listed projects are set out in the SDOT Information Infrastructure Backlog in Appendix F.

Ecosystem Policy Directions

SDOT subscribes to[48] NACTO’s policy guidance on managing mobility data (2019) that was co-prepared with the International Municipal Lawyers Association. The document provides best practices for access to and management of mobility data and “a common framework for sharing, protecting, and managing data based on four principles:

  • Data is a Public Good: Cities require data from private vendors operating on city streets to ensure positive safety, equity, and mobility outcomes on streets and places in the public right-of-way.
  • Data Should be Protected: Cities and private companies should treat geospatial mobility data as they treat personally identifiable information (PII).
  • Data Should be Collected Purposefully: Cities should be clear about when, why, and what data is necessary for planning, analysis, oversight, and enforcement purposes.
  • Data Should be Portable: Open data standards help cities and private companies to share data in universal formats, enabling cities to use data from multiple sources, and supporting innovation in both the public and private sectors.”[49]

To protect the privacy of individuals and safeguard the community, SDOT will explore the following policy directions to apply to the actors in the ecosystem:

Transportation information fiduciaries

We believe the ability of information and mobility service providers to gather vast amounts of location information about their users while controlling what information they deliver to the user is a significant power asymmetry. The location information is unique to each individual, representing how that individual moves across the city. While a single instance of geolocated data attributed to a user may be neutral, geolocated data across a geography and across time is categorically personally identifiable information.

SDOT will explore policies that designate transportation information service providers and mobility service providers as “information fiduciaries” who must maintain an explicit relationship of trust with their users and with the other actors in the system.[50]

The Electronic Frontier Foundation explains the idea:

“The law of ’fiduciaries‘ is hundreds of years old. It arises from economic relationships based on asymmetrical power, such as when ordinary people entrust their personal information to skilled professionals (doctors, lawyers, and accountants particularly). In exchange for this trust, such professionals owe their customers a duty of loyalty, meaning they cannot use their customers’ information against their customers’ interests. They also owe a duty of care, meaning they must act competently and diligently to avoid harm to their customers. These duties are enforced by government licensing boards, and by customer lawsuits against fiduciaries who do wrong.”[51]

Among the implications of exploring this policy framework, SDOT will consider the following:

  • All information and mobility service providers may be required to register with SDOT and be assigned a unique provider identifier that will be used as metadata for APIs and data feeds.
  • The unique ID may also be used to validate data agreements with other actors in the ecosystem and help track data breaches.

Policies for providers

To meet the information infrastructure and ecosystem goals, service providers must have:

  • Written and published company commitments against racism and discrimination
  • Express privacy rules and anti-surveillance commitments
  • Explainable algorithms for machine learning and AI systems
  • A framework for delivering information to users on the impact to the environment of their services
  • Commitments and protocols to notify their users and the rest of the ecosystem immediately of critical data breaches
  • Disclosure on how they use data provided and generated by their users
  • Declared strategies for delivering information via non-digital means, and means appropriate for the disabled
  • Non-digital and non-credit card payment options
  • Agreed-upon information accuracy/dependability goals (across all actors)

APIs and data feeds

To ensure that the transportation network can serve and meet the information needs of the traveling public effectively, SDOT will encourage the providers to:

  • Work with SDOT to develop APIs that will allow the provider to ingest data from SDOT and vice versa. The data from SDOT may include, but is not limited to:
    • Real-time road closures (scheduled and un-scheduled)
    • Real-time prioritized or recommended routes or re-routes
    • Curb management information (loading, parking, and ride-hailing zones)
    • Real-time parking and load zone availability
    • Geofenced areas (where pickups or drop-offs may not be allowed, or particular vehicles may be restricted)
    • Fees and rate schedules
    • Route advisories
    • Emergency advisories
  • Push out information (in feeds and APIs) on the following:
    • Estimated carbon generated per user and per trip
    • Aggregate carbon generated by all users and all trips they provide
    • For high-capacity mobility providers (trains, buses, shuttles, vanpools)
      • Routes and schedules
      • Re-routes and changes in schedule (particularly re-routes during emergencies)
      • Real-time vehicle locations while in service
      • Real-time passenger counts
      • Wait times/time to next vehicle
      • Historic reliability of each route (% of time on time or delayed)
    • For shared service providers (car-share, ride-hail, micro-mobility)
      • Aggregated origin and destination data
      • Aggregated, real-time vehicle flow data while in arterials, urban centers and urban villages (volume of vehicles, average speeds)
      • For car-share and micro-mobility, current locations and service status (usable, disabled) of available vehicles
      • Current rates/fares and historical average
    • For urban goods delivery services
      • Aggregated, real-time vehicle flow data while in arterials, urban centers and urban villages
      • Aggregated predicted delivery vehicle volumes
      • Aggregated historical data on delivery vehicle volumes
    • For map and navigation service providers
      • Aggregated (also anonymized and obscured) data on historical vehicle and traveler flows and volumes
      • Predicted vehicle and traveler flows
      • Real-time notification on unusual spikes in traffic volumes
    • Receive information from and transmit information to other providers on:
      • All available transportation options
      • Nearest available transportation (distance, time, accessibility)

Safety and security

All providers should make it easy to call for help through their vehicles, apps or interfaces. Location data about users who call for help should be transmitted readily to emergency responders.

Emergency responders should have the ability to transmit this location data to SDOT to allow traffic managers to prioritize response routes.

For vehicles that require operators, all mobility service providers should:

  • Provide the user with the identity of the vehicle operator (even if the vehicle is operated remotely)
  • Inform the user if the vehicle is operated by AI

Customer service

All providers should give their users the ability to submit complaints to SDOT about their service or about the transportation network.

System reporting

All providers should report on the following

  • Total carbon generation/savings from all their users
  • Equity outcomes
  • Security audits (such as SOC 2.0[52])
  • Anonymization protocols

SDOT Future Needs and Skillsets

To implement the policies, projects, initiatives, and technology investments outlined in this plan, SDOT has to develop new skills and capacities. These skills are necessary if SDOT is to manage an urban transportation system built on information and to engage the actors in the emerging ecosystem.

This plan recommends the following actions:

Build data awareness across the enterprise

All SDOT staff should appreciate how the department collects and stores information and data, and how the department uses the data.

The department’s onboarding process for all new hires should include introductory training sessions on SDOT’s datasets (using the SDOT Data Library). It should also schedule briefings and training sessions for existing employees so that all SDOT staff know what data is available and how to get it.

Clarify roles between SDOT and Seattle IT

The creation of Seattle IT centralized IT expertise across city government. As a result, SDOT lost its in-house IT expertise and lost some authority to make strategic technology decisions and manage mid-level system enhancements and IT projects.

SDOT needs to clarify the relationship and exercise authority over business intelligence requirements. The department’s executive leadership should involve itself with IT decisions at the strategic level.  Information technology systems purchases should be treated as strategic investments and should satisfy enterprise-wide requirements.

SDOT and IT particularly need to clarify roles and process for deploying and operating cloud-based solutions. The demands of the emerging transportation information ecosystem requires the speed and bandwidth of cloud services. The process between the two agencies must be equal to the demands for agility and speed.

Educate staff on new map technology and systems

A large contingent of SDOT staff are trained and are fluent with ESRI’s ArcGIS. A smaller number understand the spatial databases behind GIS and how they interact with map visualizations. Only a handful understand web map services or how to deliver data to web map services.

The actors of the ecosystem (information and mobility service providers) build their enterprises on web map services from the ground up. Their workforce code in the computer programming language on which these services were built (Python, GeoJSON, C#, R, etc.). While SDOT staff may not need to program or code, they should be familiar with the structure of these languages and how they work.

These skills are necessary, particularly for the Information Data Unit, as SDOT builds up its API strategy and rolls out data feeds and APIs.

Hire and/or train for skills in problem-solving, basic programming, and data analytics

The demands of the new ecosystem require more capacity in data analytics and problem-solving. Particular classes of SDOT staff should be hired with these skills along with rudimentary or basic programming skills.

SDOT’s use of data analytics will only continue to grow as more technology takes over the transportation system. Data analytics work that SDOT currently outsources may need to be brought in-house may need to be brought in-house so that the department continues to acquire institutional expertise in the data it collects.

For analyst and program positions, using spreadsheets and manipulating and querying databases should be basic skills.

SDOT should train more staff in data visualization (such as Tableau and/or Power BI).

SDOT staff should also be fully versed in open-source platforms such as GitHub or its alternatives, where a lot of open code is developed and tested.

Benchmark skills against the industry

SDOT should commission a review of the skills required by the information and mobility service providers against the department’s own workforce skills profile. This will ensure that SDOT’s teams understand their counterparts from the information and transportation providers.

Invest in in-house knowledge in machine learning and AI

The next innovations in transportation technology are being built on machine learning and AI. SDOT needs to be conversant in these technologies to manage the implications of these on transportation.

Learn Lean and Agile methodologies

The emerging ecosystem requires faster responses from SDOT and the ability to deliver new information products quickly.

Lean and Agile both focus on the needs of the customer. Lean builds a culture of continuous improvement and the elimination of process steps that do not bring value to the customer. Agile builds a culture of responsiveness and collaboration for rapid delivery of what the customer needs.

Build In-house UX/UI Testing Capacity

To better serve the information needs of users of our transportation system, SDOT needs to build a culture of user testing. User tests of proposed new processes or technologies can reveal inadequacies before they become issues. They can also save the department from locking itself into a solution that doesn’t fully meet the needs of users. In the long-run, this saves time and money for the department, and improves user experiences.

Currently, user testing is often not conducted before committing to a new process or technology, and when it is, the work is usually contracted out to expensive consultants. We need to build in-house expertise in this area so that testing can be streamlined and cost-effective.

Gain skills in product management and development

The initiatives listed in this plan require not just project management but also product management.

Here’s the difference in the roles:

“Product manager(s) —…set the strategy, prioritize releases, talk to customers, and clearly define features. Their efforts are ongoing and involve managing the entire lifecycle of the product. A product manager’s goal is to deliver a product that customers love.

Project manager(s) — oversee a fixed project from beginning to end. It can be a single project or a group of projects. Their job is to execute the strategy set by the product manager or leadership team. A project manager’s goal is to work with a broader team with a diverse set of skills and to complete a project on time and under budget.”[53]

SDOT has a deep bench in project management but little or no capacity at all in product management, particularly for information products. Product management also demands customer- or user-driven approaches.

Build communities of practice within SDOT

SDOT needs to keep up with innovations in how data is managed, handled and analyzed. The department should be intentional in sharing new knowledge and skills across its workforce.

Communities of practice will build the informal social networks and social capital SDOT needs to leverage the information it collects and to adapt to the rapidly changing ecosystem.


[41] The numbering of this section does not imply prioritization or sequencing. Instead it is about how each initiative fits with the others.

[42] SDOT’s available online maps are available at https://www.seattle.gov/transportation/permits-and-services/interactive-maps

[43] See International Transport Forum’s “Towards Road Freight Decarbonisation: Trends, Measures and Policies,” (2018).

[44] More information on Open311 here: http://www.open311.org/learn/

[45] We’ve deployed magnetometers that count vehicle volumes and in select locations, bike volumes. We use cameras to detect vehicles waiting at stoplights and are starting to use them to also track volumes, speeds, and vehicle type. We use pneumatic tubes for volume, speed, and classification studies (for vehicles and bicycles). We even have infrared beams that count pedestrians. We use portable cameras for automated turning movement counts and other traffic studies.

[46] This in partnership with KC Metro and Sound Transit, may simply involve ingesting data these agencies already collect.

[47] There are serious privacy concerns about the use of Bluetooth beacons. Beacons are “dumb” infrastructure that simply broadcast their location data, which can be picked up by sensors in phones and other devices to help in geolocation. They do not and cannot pull or store any data. However, apps using the beacon data can locate the travel patterns of individuals.

[48]and helped to review

[49] https://nacto.org/2019/05/30/managing-mobility-data/

[50] The concept of “information fiduciaries” was first raised by Kenneth Laundon in the early 1990s. Jack Balkin revived and expounded the idea starting in 2016 in reference to Facebook, Google, and other technology platforms (see Balkin, Jack M., “Information Fiduciaries and the First Amendment,” UC Davis Law Review, Vol. 49, No. 4 (2016): 1183). Lina Khan and David Pozen countered that the idea of information fiduciaries was not enough to confront the economic power of platform technologies (Khan, Lina and David E. Pozen, “A Skeptical View of Information Fiduciaries” (May 25, 2019); Harvard Law Review, Vol. 133, 2019, forthcoming; Columbia Public Law Research Paper No. 14-622. Available at SSRN: https://ssrn.com/abstract=3341661).

[51] https://www.eff.org/deeplinks/2018/10/information-fiduciaries-must-protect-your-data-privacy

[52] SOC 2 stands for SOC for Service Organizations: Trust Services Criteria, an auditing procedure developed by the American Institute of Certified Public Accountants that ensures service providers manage data securely in order to protect the interests of the organization and the privacy of its clients. https://www.imperva.com/learn/data-security/soc-2-compliance/

[53] https://blog.aha.io/the-product-manager-vs-project-manager/

Need More Information?

This is a draft plan. It was developed by Benjamin de la Pena, Mary Alyce Eugene, Alex Hagenah, and Sam Marshall along with their colleagues from across the Seattle Department of Transportation (SDOT).

If you have questions about this plan, please send us email via draft_tiip@seattle.gov.

If you have questions about SDOT, please visit our website at www.seattle.gov/transporation.

Designed by Story 2 Designs

Privacy Policy